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Abstract 


Proof-Carrying  Code  (PCC)  allows  a  code  producer  to  provide  to  a  host  a 
program  along  with  its  formal  safety  proof.  The  proof  attests  a  certain  safety 
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be  automatically  generated.  As  a  result,  many  low-level  system  libraries  ( e.g 
memory  management)  have  not  yet  been  handled.  In  this  paper,  we  explore  a 
complementary  approach  in  which  general  properties  and  program  correctness 
are  semi-automatically  certified.  In  particular,  we  introduce  a  low-level  language 
CAP  for  building  certified  programs  and  present  a  certified  library  for  dynamic 
storage  allocation. 
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Abstract.  Proof-Carrying  Code  (PCC)  allows  a  code  producer  to  pro¬ 
vide  to  a  host  a  program  along  with  its  formal  safety  proof.  The  proof 
attests  a  certain  safety  policy  enforced  by  the  code,  and  can  be  mechan¬ 
ically  checked  by  the  host.  While  this  language-based  approach  to  code 
certification  is  very  general  in  principle,  existing  PCC  systems  have  only 
focused  on  programs  whose  safety  proofs  can  be  automatically  generated. 
As  a  result,  many  low-level  system  libraries  (e.g.,  memory  management) 
have  not  yet  been  handled.  In  this  paper,  we  explore  a  complementary 
approach  in  which  general  properties  and  program  correctness  are  semi- 
automatically  certified.  In  particular,  we  introduce  a  low-level  language 
CAP  for  building  certified  programs  and  present  a  certified  library  for 
dynamic  storage  allocation. 


1  Introduction 

Proof-Carrying  Code  (PCC)  is  a  general  framework  pioneered  by  Necula  and 
Lee  [15, 13].  It  allows  a  code  producer  to  provide  a  program  to  a  host  along  with 
a  formal  safety  proof.  The  proof  is  incontrovertible  evidence  of  safety  which 
can  be  mechanically  checked  by  the  host;  thus  the  host  can  safely  execute  the 
program  even  though  the  producer  may  not  be  trusted. 

Although  the  PCC  framework  is  general  and  potentially  applicable  to  certi¬ 
fying  arbitrary  data  objects  with  complex  specifications  [14, 2],  generating  proofs 
remains  difficult.  Existing  PCC  systems  [16,12,3,1]  have  only  focused  on  pro¬ 
grams  whose  safety  proofs  can  be  automatically  generated.  As  a  result,  many 
low-level  system  libraries,  such  as  dynamic  storage  allocation,  have  not  been 
certified.  Nonetheless,  building  certified  libraries,  especially  low-level  system  li¬ 
braries,  is  an  important  task  in  certifying  compilation.  It  not  only  helps  increase 
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the  reliability  of  “infrastructure”  software  by  reusing  provably  correct  program 
routines,  but  also  is  crucial  in  making  PCC  scale  for  production. 

On  the  other  hand,  Hoare  logic  [7, 8],  as  a  widely  applied  approach  in  program 
verification,  allows  programmers  to  express  their  reasonings  with  assertions  and 
the  application  of  inference  rules,  and  can  be  used  to  prove  general  program  cor¬ 
rectness.  In  this  paper,  we  introduce  a  conceptually  simple  low-level  language  for 
certified  assembly  programming  (CAP)  that  supports  Hoare-logic  style  reason¬ 
ing.  We  use  CAP  to  build  a  certified  library  for  dynamic  storage  allocation,  and 
further  use  this  library  to  build  a  certified  program  whose  correctness  proof  can 
be  mechanically  checked.  Applying  Hoare-logic  reasonings  at  an  assembly-level, 
our  paper  makes  the  following  contributions: 

-  CAP  is  based  on  a  common  instruction  set  so  that  programs  can  be  executed 
on  real  machines  with  little  effort.  The  expected  behavior  of  a  program  is 
explicitly  written  as  a  specification  using  higher-order  logic.  The  programmer 
proves  the  well-formedness  of  a  program  with  respect  to  its  specification 
using  logic  reasoning,  and  the  result  can  be  checked  mechanically  by  a  proof- 
checker.  The  soundness  of  the  language  guarantees  that  if  a  program  passes 
the  static  proof-checking,  its  run-time  behavior  will  satisfy  the  specification. 

-  Using  CAP,  we  demonstrate  how  to  build  certified  libraries  and  programs. 
The  specification  of  library  routines  are  precise  yet  general  enough  to  be 
imported  in  various  user  programs.  Proving  the  correctness  of  a  user  program 
involves  linking  with  the  library  proofs. 

-  We  implemented  CAP  and  the  dynamic  storage  allocation  routines  using  the 
Coq  proof  assistant  [20],  showing  that  this  library  is  indeed  certified.  The 
example  program  is  also  implemented.  All  the  Coq  code  is  available  [21]. 

-  Lastly,  memory  management  is  an  important  and  error-prone  part  of  most 
non-trivial  programs.  It  is  also  considered  to  be  hard  to  certify  by  previous 
researches.  We  present  a  provably  correct  implementation  of  a  typical  dy¬ 
namic  storage  allocation  algorithm.  To  the  authors’  knowledge,  it  is  so  far 
the  only  certified  library  for  memory  management. 


2  Dynamic  Storage  Allocation 

In  the  remainder  of  this  paper,  we  focus  on  the  certification  and  use  of  a  library 
module  for  dynamic  storage  allocation.  In  particular,  we  implement  a  storage 
allocator  similar  to  that  described  in  [10,11].  The  interface  to  our  allocator 
consists  of  the  standard  malloc  and  free  functions.  The  implementation  keeps 
track  of  a  free  list  of  blocks  which  are  available  to  satisfy  memory  allocation 
requests.  As  shown  in  Figure  1,  the  free  list  is  a  null-terminated  list  of  (non¬ 
contiguous)  memory  blocks.  Each  block  in  the  list  contains  a  header  of  two 
words:  the  first  stores  a  pointer  to  the  next  block  in  the  list,  and  the  second 
stores  the  size  of  the  block.  The  allocated  block  pointer  that  is  returned  to  a 
user  program  points  to  the  useable  space  in  the  block,  not  to  the  header. 
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Fig.  1.  Free  list  and  free  blocks. 


The  blocks  in  the  list  are  sorted  in  order  of  increasing  address  and  requests 
for  allocation  are  served  based  on  a  first-fit  policy;  hence,  we  implement  an 
address- ordered  first-fit  allocation  mechanism.  If  no  block  in  the  free  list  is  big 
enough,  or  if  the  free  list  is  empty,  then  malloc  requests  more  memory  from  the 
operating  system  as  needed.  When  a  user  program  is  done  with  a  memory  block, 
it  is  returned  to  the  free  list  by  calling  free,  which  puts  the  memory  block  into 
the  free  list  at  the  appropriate  position. 

Our  implementation  in  this  paper  is  simple  enough  to  understand,  yet  faith¬ 
fully  represents  mechanisms  used  in  traditional  implementations  of  memory  al¬ 
locators  [22, 10, 11].  For  ease  of  presentation,  we  assume  our  machine  never  runs 
out  of  memory  so  malloc  will  never  fail,  but  otherwise  many  common  low-level 
mechanisms  and  techniques  used  in  practice  are  captured  in  this  example,  such 
as  use  of  a  free  list,  in-place  header  fields,  searching  and  sorting,  and  splitting 
and  coalescing  (described  below) .  We  thus  believe  our  techniques  can  be  as  easily 
applied  to  a  variety  of  other  allocator  implementations  than  described  here. 

In  the  remainder  of  this  section,  we  describe  in  detail  the  functionality  of  the 
malloc  and  free  library  routines  (Figure  2),  and  give  some  “pseudo-code”  for 
them.  We  do  not  show  the  calloc  (allocate  and  initialize)  and  realloc  (resize 
allocated  block)  routines  because  they  essentially  delegate  their  tasks  to  the  two 
main  functions  described  below. 

free  This  routine  puts  a  memory  block  into  the  free  list.  It  takes  a  pointer 
(ptr)  to  the  useable  portion  of  a  memory  block  (preceded  by  a  valid  header) 
and  does  not  return  anything.  It  relies  on  the  preconditions  that  ptr  points  to 
a  valid  “memory  block”  and  that  the  free  list  is  currently  in  a  good  state  (i.e., 
properly  sorted).  As  shown  in  Figure  2,  free  works  by  walking  down  the  free 
list  to  find  the  appropriate  (address-ordered)  position  for  the  block.  If  the  block 
being  freed  is  directly  adjacent  with  either  neighbor  in  the  free  list,  the  two  are 
coalesced  to  form  a  bigger  block. 

malloc  This  routine  is  the  actual  storage  allocator.  It  takes  the  size  of  the 
new  memory  block  expected  by  the  user  program,  and  returns  a  pointer  to  an 
available  block  of  memory  of  that  size.  As  shown  in  Figure  2,  malloc  calculates 
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void  free  (void*  ptr)  { 

hp  =  ptr  -  header_size;  //  move  to  header 

for  (prev  =  nil,  p  =  flist;  p  <>  nil;  prev  =  p,  p  =  p->next) 

if  (hp  <  p)  {  //  found  place 

if  (hp  +■  hp->size  ==  p)  //  join  or  link  with  upper  neighbor 

hp->size  +=  p->size,  hp->next  =  p->next; 
else  hp->next  =  p; 

if  (prev  <>  nil)  //  join  or  link  with  lower  neighbor 

if  (prev  +  prev->size  ==  hp) 

prev->size  +=  hp->size,  prev->next  =  hp->next; 
else  prev->next  =  hp; 
else  flist  =  hp; 
return ; 

> 

hp->next  =  nil;  //  block’s  place  is  at  end  of  the  list 

if  (prev  <>  nil)  //  join  or  link  with  lower  neighbor 

if  (prev  +  prev->size  ==  hp) 

prev->size  +=  hp->size,  prev->next  =  hp->next; 
else  prev->next  =  hp; 
else  flist  =  hp; 

> 

void*  malloc  (int  reqsize)  { 

actual_size  =  reqsize  +  header_size; 

for (prev  =  nil,  p  =  flist;  ;  prev  =  p,  p  =  p->next) 

if  (p==nil)  {  //  end  of  free  list,  request  more  memory 

more_mem(actual_size) ; 

prev  =  nil,  p  =  flist;  //  restart  the  loop  search 

}  else  if  (p->size  >  actual_size  +  header_size)  { 

p->size  -=  actual_size;  //  found  block  bigger  than  needed 

p  +=  p->size;  //  by  more  than  a  header  size, 

p->size  =  actual_size;  //  so  split  into  two 

return  (p  +  header_size) ; 

}  else  if  (p->size  >=  actual_size)  {  //  found  good  enough  block 

if  (prev==nil)  flist  =  p->next;  else  prev->next  =  p->next; 
return  (p  +  header_size) ; 

> 

> 

void  more_mem(int  req_size)  { 

if  (req_size  <  NALLOC)  req_size  =  NALLOC;  //  request  not  too  small 

q  =  alloc (req_size) ;  //  call  system  allocator 

q->size  =  req_size; 

free(q  +  header_size) ;  //  put  new  block  on  free  list 

} 

Fig.  2.  Pseudo  code  of  allocation  routines. 


the  actual  size  of  the  block  needed  including  the  header  and  then  searches  the 
free  list  for  the  first  available  block  with  size  greater  than  or  equal  to  what  is 
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required.  If  the  size  of  the  block  found  is  large  enough,  it  is  split  into  two  and  a 
pointer  to  the  tail  end  is  returned  to  the  user. 

If  no  block  in  the  free  list  is  large  enough  to  fulfill  the  request,  more  memory  is 
requested  from  the  system  by  calling  moreunem.  Because  this  is  a  comparatively 
expensive  operation,  more_mem  requests  a  minimum  amount  of  memory  each  time 
to  reduce  the  frequency  of  these  requests.  After  getting  a  new  chunk  of  memory 
from  the  system,  it  is  appended  onto  the  free  list  by  calling  free. 

These  dynamic  storage  allocation  algorithms  often  temporarily  break  certain 
invariants,  which  makes  it  hard  to  automatically  prove  their  correctness.  During 
intermediate  steps  of  splitting,  coalescing,  or  inserting  memory  blocks  into  the 
free  list,  the  state  of  the  free  list  or  the  memory  block  is  not  valid  for  one  or 
two  instructions.  Thus,  a  traditional  type  system  would  need  to  be  extremely 
specialized  to  be  able  to  handle  such  code. 

3  A  Language  for  Certified  Assembly  Programming  (CAP) 

To  write  our  certified  libraries,  we  use  a  low-level  assembly  language  CAP  fitted 
with  specifications  reminiscent  of  Hoare-logic.  The  assertions  that  we  use  for 
verifying  the  particular  dynamic  allocation  library  described  in  this  paper  are 
inspired  by  Reynolds’  “separation  logic”  [19,18]. 

The  syntax  of  CAP  is  given  in  Figure  3.  A  complete  program  (or,  more 
accurately,  machine  state)  consists  of  a  code  heap,  a  dynamic  state  component 
made  up  of  the  register  file  and  data  heap,  and  an  instruction  sequence.  The 
instruction  set  captures  the  most  basic  and  common  instructions  of  an  assembly 
language,  and  includes  primitive  alloc  and  free  commands  which  are  to  be  viewed 
as  system  calls.  The  register  file  is  made  up  of  32  registers  and  we  assume  an 
unbounded  heap  with  integer  words  of  unlimited  size  for  ease  of  presentation. 

Our  type  system,  as  it  were,  is  a  very  general  layer  of  specifications  such 
that  assertions  can  be  associated  with  programs  and  instruction  sequences.  Our 
assertion  language  ( Assert )  is  the  calculus  of  inductive  constructions  (CiC)  [20, 
17],  an  extension  of  the  calculus  of  constructions  [4]  which  is  a  higher-order  typed 
lambda  calculus  that  corresponds  to  higher-order  predicate  logic  via  the  Curry- 
Howard  isomorphism  [9].  In  particular,  we  implement  the  system  described  in 
this  paper  using  the  Coq  proof  assistant  [20].  Assertions  are  thus  defined  as  Coq 
terms  of  type  State  ->  Prop,  where  the  various  syntactic  categories  of  the  assembly 
language  (such  as  State)  have  been  encoded  using  inductive  definitions.  We  give 
examples  of  inductively  defined  assertions  used  for  reasoning  about  memory  in 
later  sections. 


3.1  Operational  Semantics 

The  operational  semantics  of  the  assembly  language  is  fairly  straightforward  and 
is  defined  in  Figures  4  and  5.  The  former  figure  defines  a  “macro”  relation  de¬ 
tailing  the  effect  of  simple  instructions  on  the  dynamic  state  of  the  machine. 
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(Program) 

P 

:=  (C,S,I) 

(Command)  c 

:=  add  Td,  rs,r 

I  addi  rd,r 

( GodeHeap) 

C 

:=  {f  -v*  I}* 

|  sub  Td,rs,rt 

|  subl  rd,  rs 

(State) 

s 

:=  (H,  R) 

|  mov  rd,rs  | 

movi  r d,  i 

(Heap) 

H 

:=  {1  ^  w}‘ 

|  bgt  rs,  rt,  f 

bgti  rs,i,f 

(RegFile) 

R 

:=  {r  w}’ 

|  alloc  r<i[r.,]  | 

Id  Td,rs(i) 

(Register) 

(Labels) 

r 

f,l 

:=  {r,}*e<0"31> 

:=  i  (nat  nums) 

(GdHpSpec)  S' 

|  st  rd(i),Ts  | 

free  rs 

(WordVal) 

w 

:=  i  (nat  nums) 

:=  {f  ^  a}* 

(InstrSeq) 

I 

■=  c;I  |  jd  f  |  jmp  r 

(Assert)  a 

:=  . . . 

Fig.  3.  Syntax  of  CAP. 


Control-flow  instructions,  such  as  jd  or  bgt,  do  not  affect  the  data  heap  or  reg¬ 
ister  file.  The  domain  of  the  heap  is  altered  by  either  an  alloc  command,  which 
increases  the  domain  with  a  specified  number  of  labels  mapped  to  undefined 
data,  or  by  free,  which  removes  a  label  from  the  domain  of  the  heap.  The  Id  and 
st  commands  are  used  to  access  or  update  the  value  stored  at  a  given  label. 

Since  we  intend  to  model  realistic  low-level  assembly  code,  we  do  not  have  a 
“halt”  instruction.  In  fact,  termination  is  undesirable  since  it  means  the  machine 
has  reached  a  “stuck”  state  where,  for  example,  a  program  is  trying  to  branch  to 
a  non-existent  code  label,  or  access  an  invalid  data  label.  We  present  in  the  next 
section  a  system  of  inference  rules  for  specifications  which  allow  one  to  statically 
prove  that  a  program  will  never  reach  such  a  bad  state. 


3.2  Inference  Rules 


We  define  a  set  of  inference  rules  allowing  us  to  prove  specification  judgments 
of  the  following  forms: 

b  {a}  P  (well- formed  program ) 

S'  b  C  ( well-formed  code  heap ) 

S'  b  {a}  I  ( well-formed  instruction  sequence) 

Programs  in  our  assembly  language  are  written  in  continuation-passing  style 
because  there  are  no  call/return  instructions.  Hence,  we  only  specify  precondi¬ 
tions  for  instruction  sequences.  (Preconditions  of  the  continuations  actually  serve 
as  the  postconditions.)  If  a  given  state  satisfies  the  precondition,  the  sequence 
of  instructions  will  run  without  reaching  a  bad  state.  Furthermore,  in  order  to 
check  code  blocks,  which  are  potentially  mutually  recursive,  we  require  that  all 
labels  in  the  code  heap  be  associated  with  a  precondition-  this  mapping  is  our 
code  heap  specification,  S'. 


Well-formed  code  heap  and  programs  A  code  heap  is  well-formed  if  the  code  block 
associated  with  every  label  in  the  heap  is  well-formed  under  the  corresponding 
precondition.  Then,  a  complete  program  is  well-formed  if  the  code  heap  is  well- 
formed,  the  current  instruction  sequence  is  well-formed  under  the  precondition, 
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if  c  = 

then  AuxStep(c,  (H,  R))  = 

add  rd,rs,rt 

(H,  R{rd  R(rs)  +  R(rt)}) 

addi  rd,rs,  i 

(H,  R{rd  ^  R(rs)  +  *}) 

sub  rd,rs,r t 

(H,  R{rd  R(rs)  —  R(rt)}) 

subi  id,  is,  i 

(Bf  R{rd  R(rs)  —  j}) 

mov  id,  is 

(HU,  R{rd  ^  K(ra)}) 

movi  Td ,  w 

(H,  R{rd  w}) 

Fig.  4.  Auxiliary  state  update  macro. 


and  the  precondition  also  holds  for  the  dynamic  state. 

dom(\f')  =  dom(C)  \P  b  {<P’(f)}C(f )  V/ €  dom(’P’) 

«P  (-  C 


!?I-C  <Pb{a}I  (aS) 
!?h{a}  (C,  S,I) 


(2) 


Well-formed  instructions:  Pure  rules  The  inference  rules  for  instruction  se¬ 
quences  can  be  divided  into  two  categories:  pure  rules,  which  do  not  interact 
with  the  data  heap,  and  impure  rules,  which  deal  with  access  and  modification 
of  the  data  heap. 

The  structure  of  many  of  the  pure  rules  is  very  similar.  They  involve  showing 
that  for  all  states,  if  an  assertion  a  holds,  then  there  exists  an  assertion  a' 
which  holds  on  the  state  resulting  from  executing  the  current  command  and, 
additionally,  the  remainder  of  the  instruction  sequence  is  well-formed  under  a'. 
We  use  the  auxiliary  state  update  macro  defined  in  Figure  4  to  collapse  the  rules 
for  arithmetic  instructions  into  a  single  schema.  For  control  flow  instructions, 
we  instead  require  that  if  the  current  assertion  a  holds,  then  the  precondition  of 
the  label  that  is  being  jumped  to  must  also  be  satisfied. 


c  e  {add,  addi,  sub,  subi,  mov,  movi} 

VBL  VR.  a  (H,  R)  Da!  (AuxStep(c,  (H,  R)))  b  {a'}  I 

.  <Fb  {a}c;I 

VBL  VR.  (R(rs)  <  R(rt))  D  a  (H,  R)  D  a'  (H,  R) 

VBL  VR.  (R(rs)  >  R(rt))  D  a  (H,  R)  D  ax  (H,  R) 
^bja'}!  !f(f)  =  ai 

&  F  {a}  bgt  rs,rt)f;I 

VBL  VR.  (R(rs)  <  i)Da  (H,  R)  D  a'  (H,  R) 

VBL  VR.  (R(t3)  >  i)  D  a  (H,  R)  D  ai  (H,  R) 

<P  b  {a'}  I  <P(f)  =  ai 

b  {a}  bgti  rs,  i,f;I 

VS.aSDaiS  where  •P'(f)  =  ai 
b  {a}  jd  f 


(3) 


(4) 


(5) 

(6) 
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(C,  (H,  R),  I)  i — >■  P  where 

if  1  = 

then  P  = 

j  d  f 

(C,  (H,  R),  I')  where  C(f)  =  K' 

jmp  r 

(C,  (H,  R),  V)  where  C(R(r))  =  I' 

bgt  rs,rt,f;I' 

(C,  (H,  R),  I')  when  R(rs)  <  R(rt);  and 

(C,  (H,  R),  I")  when  R(rs)  >  R(rf)  where  C(f )  =  I" 

bgti  rs, 

(C,  (H,  R),  I')  when  R(rs)  <  i ;  and 

(C,  (H,  R),  I")  when  R(rs)  >  i  where  C(f )  =  I" 

alloc  rd[rs];  I' 

(C,  (ff,R{r<,~*l}),I') 

where  R(rs)  =  i,  Hf  —  H{1  ...,  1  +  i  —  1  ^ 

and  {1, . . . ,  1  +  i  —  1}  D  dom(H)  =  0 

BA mm 

(C,  (BT.R),!')  where  VI  €  dom(lf ).Kf  (1)  =  H(l), 

R(ra)  6  dom(H),  and  dom(Bf)  =  dom(H)  —  R(rs) 

Id  rd, rs(«); I' 

(€,  (H,  R{rd  H(R(rs)  +  j)}),  I') 
where  (R(rs)  +  i)  €  dom(H) 

st  rd(i),r4;I' 

(C,  (H{R(rd)  +  i  R(r, )},  R),  I') 

where  (R(rd)  +  i)  €  dom(H) 

c;  I'  for  remaining  cases  of  c 

(C,  AuxStep(c,  (H,  R)),  I') 

Fig.  5.  Operational  semantics. 


VBL  VR.  a  (H,  R)  O  ai  (H,  M)  where  >P'(R(r))  =  ai 
S'  1-  {a}jmp  r 


(7) 


Well-formed,  instructions:  Impure  rules  As  mentioned  previously,  these  rules 
involve  accessing  or  modifying  the  data  heap. 


VHL  VR.  a  (H,  R)  D  a '  (H{1  . . . ,  1  +  i  —  1  R{rd  1}) 

where  R(rs)  =  i  and  {1, . . . ,  1  +  i  —  1}  fl  dom(H)  =  0 
S'b  {a'}  I 

S'  b  {a}  alloc  rd[rs];I 


(8) 


VBL  VR.  a  (H,  R)  D  ((R(rs)  +  i)  e  dom(B))  A  (a'  (H,  R{rd  ^  H(R(rs)  +  i)})) 
S'b  {a'}  I 

S'  b  {a}  Id  rd,  rs(i);  I 

VHVR.a(H,R)D((R(rd)-M)  €  dom(H))  A  (a'  (H{R(rd)  +  i  ^  R(rs)},R)) 
S'  b  {a'}  I 

S'  b  {a}  st  rd(i),rs;I 

VBL  VR.  a  (H,  R)  D  (R(rs)  6  dom(H))  A  (a'  (If ,  R)) 
where  dom(Hf)  =  dom(H)  —  R(rs)  and  Vl  €  dom(Bf  ).Hr  (l)  =  H(l) 

S'  b  {a'}  I 

S'  b  {a}  free  r„;  I 


(9) 


(10) 


(11) 


3.3  Soundness 

We  establish  the  soundness  of  these  inference  rules  with  respect  to  the  opera¬ 
tional  semantics  of  the  machine  following  the  syntactic  approach  of  proving  type 
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soundness  [23].  From  “Type  Preservation”  and  “Progress”  lemmas  (proved  by 
induction  on  I),  we  can  guarantee  that  given  a  well-formed  program,  the  current 
instruction  sequence  will  be  able  to  execute  without  getting  “stuck.”  Further¬ 
more,  at  the  point  when  the  current  instruction  sequence  branches  to  another 
code  block,  the  machine  state  will  always  satisfy  the  precondition  of  that  block. 

Lemma  1  (Type  Preservation) .  If  \P  P  {  a}  (C,  8 , 1)  and  (C,  § ,  I)  i — »  P,  then 
there  exists  an  assertion  a'  such  that  P  {a'}  P. 

Lemma  2  (Progress).  J/<F  P  {a}  (C, 8,1),  then  there  exists  a  program  P  such 
that  (C, 8,1)  i — »  P. 

Theorem  1  (Soundness).  If  1/  P  {a}  (C, 8,1),  then  there  exists  a  program  P 
such  that  (C,  8, 1)  t — >  P,  and 

-  if  (C,  8 , 1)>— >* (C,  S',  jd  /),  then  <F(/)  S'; 

-  if  (C,  8,  J)i — >*(C,  (H,  R),  jmp  rd),  then  V(R(rd))  (H,R); 

-  if( C,S,I)i — >*(C,(H,R),(bgt  rs,rt,f))  and E(rs)  >  R(r(),  thenl'(f)  (H,E); 

-  i/(C,8,I)i — >■*(€,  (H,  E),  (bgti  rs,i,f))  and  E(rs)  >  i,  then^(f)  (H,E). 

It  should  be  noted  here  that  this  soundness  theorem  establishes  more  than 
simple  type  safety.  In  addition  to  that,  it  states  that  whenever  we  jump  to  a 
block  of  code  in  the  heap,  the  specified  precondition  of  that  code  (which  is  an 
arbitrary  assertion)  will  hold. 

4  Certified  Dynamic  Storage  Allocation 

Equipped  with  CAP,  we  are  ready  to  build  the  certified  library.  In  particular, 
we  provide  provably  correct  implementation  for  the  library  routines  free  and 
malloc.  The  main  difficulties  involved  in  this  task  are:  (1)  to  give  precise  yet 
general  specifications  to  the  routines;  (2)  to  prove  as  theorems  the  correctness  of 
the  routines  with  respect  to  their  specifications;  (3)  the  specifications  and  theo¬ 
rems  have  to  be  modular  so  that  they  can  interface  with  user  programs.  In  this 
section,  we  discuss  these  problems  for  free  and  malloc  respectively.  From  now 
on,  we  use  the  word  “specification”  in  the  wider  sense,  meaning  anything  that 
describes  the  behavior  of  a  program.  To  avoid  confusion,  we  call  the  language 
construct  <P  a  code  heap  spec,  or  simply  spec. 

Before  diving  into  certifying  the  library,  we  define  some  assertions  related  to 
memory  blocks  and  the  free  list  as  shown  in  Figure  6.  These  definitions  make 
use  of  some  basic  operators  (which  we  implement  as  shorthands  using  primitive 
constructs)  commonly  seen  in  separation  logic  [19, 18].  In  particular,  emp  asserts 
that  the  heap  is  empty;  e  >-»  e!  asserts  that  the  heap  contains  one  cell  at  address 
e  which  contains  e';  and  separating  conjunction  p*q  asserts  that  the  heap  can 
be  split  into  two  disjoint  parts  in  which  p  and  q  hold  respectively. 

Memory  block  (MBIk  p  q  s)  asserts  that  the  memory  at  address  p  is  preceded 
by  a  pair  of  words:  the  first  word  contains  q,  a  (possibly  null)  pointer  to  another 
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MBlk  pq  s 


MBlk  p  q  s 

=  (p  >  2)  A  (s  >  2)  A 
( p  —  2t~>q)*(p  —  li->s) 
*{p,---,P+s-  3 

MBIkLst  0  p  q 

=  empA(p  =  q) 

MBIkLst  (n  +  1)  p  q 

=  3p'.(MBIk  (p  +  2)  p'  _) 

♦  (MBIkLst  n  p'  g) 

A (p  <  p'  V  p'  =  nil) 

EndL  /list  p  g 

=  ((p  =  nil)  D  (MBIkLst  0  flist  q)) 
A (p  7^  nil 

D3n.  ((MBIkLst  n  flist  p) 
*(MBIk  (p  +  2)  g  _) 

A(p  <  g  V  g  =  nil))) 

MidL  flist  p  q 

~  3n.(EndL  flist  p  q) 

♦  (MBIkLst  n  q  nil) 

Good  flist 

=  3n. (MBIkLst  n.  flist  nil) 

Vp.  Vg.  (MidL  flist  p  q)  D  (Good  flist) 


MBIkLst  n  p  q 


EndL  flist  p  q 


p-2  p-1  p  p+s-3 

E 

s 

E 

£ 


y 


flist 


Py 


;o 


:::o 

zzn 

ZD 

Z.'ZO 


MidL  flist  p  q 


flist 


Fig.  6.  Assertions  on  free  list. 


memory  block,  and  the  second  word  contains  the  size  of  the  memory  block  itself 
(including  the  two- word  header  preceding  p). 

Memory  block  list  (MBIkLst  n  p  q)  models  an  address-ordered  list  of  blocks. 
n  is  the  number  of  blocks  in  the  list,  p  is  the  starting  pointer  and  q  is  the 
ending  pointer.  This  assertion  is  defined  inductively  and  is  a  specialized  version 
of  the  singly-linked,  list  introduced  by  Reynolds  [19,18].  However,  unlike  the 
somewhat  informal  definition  of  singly-linked  list,  MBIkLst  has  to  be  defined 
formally  for  mechanical  proof-checking.  Thus  we  use  a  Coq  inductive  definition 
for  this  purpose.  In  contrast,  if  the  assertion  language  is  defined  syntactically, 
inductive  definitions  have  to  be  defined  in  the  assertion  language,  which  is  not 
shown  in  previous  work. 

A  list  with  ending  block  (EndL  flist  p  q )  is  defined  as  a  list  flist  of  memory 
blocks  with  p  pointing  at  the  last  block  whose  forward  pointer  is  q.  In  the  special 
case  that  flist  is  an  empty  list,  p  and  q  are  nil.  (MidL  flistp  q)  models  a  list 
with  a  block  B  in  the  middle,  where  the  list  starts  from  flist ,  and  the  block  B  is 
specified  by  the  position  p  and  the  forward  pointer  q.  This  assertion  is  defined  as 
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the  separating  conjunction  of  a  list  with  ending  block  B  and  a  null-terminated 
list  starting  from  the  forward  pointer  of  B. 

Finally  we  define  a  good  free  list  (Good)  as  a  null-terminated  memory  block 
list.  It  is  easy  to  show  the  relation  between  MidL  and  Good  as  described. 


free  Putting  aside  the  syntax  for  the  moment,  a  specification  which  models  the 
expected  behavior  of  free  can  be  written  as  the  following  Hoare  triple: 

{PRE}  fr ee(fptr)  { POST }; 

where  PRE  =  Pred  *  (MBIk  fptr  -  -)  *  (Good  flist) 

POST  =  Pred  *  (Good  flist ) 

Assertion  PRE  states  the  precondition.  It  requires  that  the  heap  can  be  sep¬ 
arated  into  three  disjoint,  parts,  where  fptr  points  to  a  memory  block  to  be 
freed;  flist  points  to  a  good  free  list;  and  the  remaining  part  satisfies  the  user 
specified  assertion  Pred.  Assertion  POST  states  the  postcondition.  Since  the 
memory  block  is  placed  into  the  free  list,  the  heap  now  can  be  separated  into 
two  disjoint  parts:  flist  still  points  to  a  good  free  list,  and  the  remaining  part 
of  the  heap  still  satisfies  Pred  because  it  is  untouched. 

Note  that  this  does  not  totally  specify  all  the  behaviors  of  free.  For  example, 
it  is  possible  to  add  in  the  postcondition  that  the  memory  block  that  fptr  pointed 
to  is  now  in  the  free  list.  However,  this  is  irrelevant  from  a  library  user’s  point 
of  view.  Thus  we  favor  the  above  specification,  which  guarantees  that  free  does 
not  affect  the  remaining  part  of  the  heap. 

Now  we  write  this  specification  in  CAP,  where  programs  are  written  in 
continuation-passing  style.  Before  free  completes  its  job  and  jumps  to  the  return 
pointer,  the  postcondition  should  be  established.  Thus  the  postcondition  can  be 
interpreted  as  the  precondition  of  the  code  referred  to  by  the  return  pointer. 
Suppose  r0  is  the  return  pointer,  a  valid  library  call  to  free  should  require  that 
POST  implies  <F(E(r0))  for  all  states  (which  we  write  as  POST==^T(R(xo)))- 
In  fact,  this  condition  is  required  for  type-checking  the  returning  code  of  free 
(he.,  jmp  r0).  As  a  library  routine,  free  is  expected  to  be  used  in  various  pro¬ 
grams  with  different  code  heap  specs  (<?).  So  the  above  condition  has  to  be 
established  by  the  user  with  the  actually  knowledge  of  ’I'.  When  proving  the 
well-formedness  of  free,  this  condition  is  taken  as  a  premise. 

At  an  assembly-level,  most  non-trivial  programs  are  expressed  as  multiple 
code  blocks  connected  together  with  control  flow  instructions  (jd,  jmp  and  bgt). 
Type-checking  these  control  flow  instructions  requires  similar  knowledge  about 
the  code  heap  spec  T.  For  instance,  at  the  end  of  the  code  block  free,  an  asser¬ 
tion  Aiter  is  established  about  the  current  state,  and  the  control  is  transferred 
to  the  code  block  iter  with  a  direct  jump.  When  type-checking  this  direct  jump 
(he.,  jd  iter)  against  the  assertion  Ailcr ,  the  inference  rule  6  requires  that  AiLeT 
implies  'i'(iter)  for  all  states.  These  requirements  are  also  taken  as  premises  in 
the  well-formedness  theorem  of  free.  Thus  the  specification  of  free  is  actually 
as  follows: 

VPred.  Vflt  Vf .  ( POST  =>  <P(f ))  A  ( Aiter  =>  <p(iter)) 

D'P  h  {PRE  A  R(ro)  =  f}  C(free) 


11 


where  C(free)  is  the  code  block  labeled  free,  r0  holds  the  return  location, 
and  universally  quantified  Pred  occurs  inside  the  macros  PRE  and  POST  as 
defined  before.  This  is  defined  as  a  theorem  and  formally  proved  in  Coq. 

Following  similar  ideas,  the  well-formedness  of  all  the  other  code  blocks  im¬ 
plementing  the  library  routine  free  are  also  modeled  and  proved  as  theorems, 
with  the  premises  changed  appropriately  according  to  which  labels  they  refer  to. 

Using  the  Coq  proof-assistant,  proving  these  theorems  is  not  difficult.  Pure 
instructions  only  affect  the  register  file;  they  are  relatively  easy  to  handle.  Impure 
instructions  affect  the  heap.  Nonetheless,  commonalities  on  similar  operations 
can  be  factored  out  as  lemmas.  For  instance,  writing  into  the  “link”  field  of  a 
memory  block  header  occurs  in  various  places.  By  factoring  out  this  behavior  as 
a  lemma  and  applying  it,  the  proof  construction  becomes  simple  routine  work. 
The  only  tricky  part  lies  in  proving  the  code  which  performs  coalescing  of  free 
blocks.  This  operation  essentially  consists  of  two  steps:  one  to  modify  the  size 
field;  the  other  to  combine  the  blocks.  No  matter  which  one  is  performed  first, 
one  of  the  blocks  has  to  be  “broken”  from  being  a  valid  memory  block  as  required 
by  MBIk.  This  behavior  is  hard  to  handle  in  conventional  type  systems,  because 
it  tends  to  break  certain  invariants  captured  by  the  type  system. 

In  Figure  9  of  Appendix  A,  we  give  the  routine  free  written  in  CAP.  This 
program  is  annotated  with  assertions  at  various  program  points.  It  contains  the 
spec  templates  (the  assertions  at  the  beginning  of  every  code  block),  and  can 
be  viewed  as  an  outline  of  the  proof.  In  this  program,  variables  are  used  instead 
of  register  names  for  ease  of  understanding.  We  also  assume  all  registers  to  be 
caller-saved,  so  that  updating  the  register  file  does  not  affect  the  user  customized 
assertion  Fred.  Typically  relevant  states  are  saved  in  activation  records  in  a  stack 
when  making  function  calls,  and  Pred  would  be  dependent  only  on  the  stack. 
In  the  current  implementation,  we  have  not  yet  provided  certified  activation 
records;  instead,  we  simply  use  different  registers  for  different  programs. 

A  certified  library  routine  consists  of  both  the  code  and  the  proof.  Accord¬ 
ingly,  the  interface  of  such  a  routine  consists  of  both  the  signature  (parameters) 
and  the  spec  templates  ( e.g PRE, POST).  When  the  routine  is  used  by  a  user 
program,  both  the  parameters  and  the  spec  templates  should  be  instantiated 
properly.  The  well-formedness  of  free  is  also  a  template  which  can  be  applied 
to  various  assertion  Pred,  code  heap  spec  T  and  returning  label  /.  If  a  user  pro¬ 
gram  contains  only  one  call-site  to  free,  the  corresponding  assertion  for  free 
should  be  used  in  T.  However,  if  a  user  program  contains  multiple  call-sites  to 
free,  a  “sufficiently  weak”  assertion  for  free  must  be  constructed  by  building  a 
disjunction  of  all  the  individually  instantiated  assertions.  The  following  derived 
Rule  12  (which  is  proved  by  induction  on  I),  together  with  the  theorem  for  the 
well-formedness  of  free,  guarantees  that  the  program  type-checks. 


«?i-{ai}n  «p-b{a2}I 

<P  h  {ai  V  a2}  I 


(12) 
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malloc  Similarly  as  for  free,  an  informal  specification  of  malloc  can  be  de¬ 
scribed  as  follows: 

{PRE}  malloc(nsize,  mptr)  {POST}] 

where  PRE  =  Pred  *  (Good  flist)  A  ( nsize  —  so  >  0) 

POST  =  Pred'  *  (Good  flist)  *  (MBIk  mptr  _  s)  A  (so  +  2  <  s) 

The  precondition  PRE  states  that  flist  points  to  a  good  free  list,  user  cus¬ 
tomized  assertion  Pred  holds  for  the  remaining  part  of  the  heap,  and  the  re¬ 
quested  size  nsize  is  larger  than  0.  The  postcondition  POST  states  that  part 
of  the  heap  is  the  newly  allocated  memory  block  pointed  to  by  mptr  whose  size 
is  at  least  the  requested  one,  flist  still  points  to  a  good  free  list,  and  another 
assertion  Pred'  holds  for  the  remaining  part  of  the  heap.  Pred'  may  be  different 
from  Pred  because  malloc  modifies  register  mptr.  The  relation  between  these 
two  assertions  is  described  by  SIDE  as  follows: 

SIDE  =  V(H,  R).  Pred  (H,  R)  D  Pred'  (H,  R {mptr  ^  .}) 

Typically,  Pred  does  not  depend  on  mptr.  So  Pred'  is  the  same  as  Pred  and 
the  above  condition  is  trivially  established. 

To  type-check  the  control-flow  instructions  of  routine  malloc  without  know¬ 
ing  the  actual  code  heap  spec  T,  we  add  premises  to  the  well-formedness  theorem 
of  malloc  similarly  as  we  did  for  free.  The  specification  in  CAP  is  as  follows: 

VPred.VPred' .  Vs0.  V<£\  Vf .  SIDE  A  (POST  =>'P(f))  A  (A;njj  =S-'P'(init)) 

D>P  h  {PRE  A  R(ri)  =  f}  C(malloc) 

where  C(malloc)  is  the  code  block  labeled  malloc,  universally  quantified  Pred, 
Pred'  and  so  occurs  inside  the  macros  PRE,  POST  and  SIDE,  init  is  the  label 
of  a  code  block  that  malloc  refers  to,  and  Ainu  is  the  assertion  established  when 
malloc  jumps  to  init.  Because  malloc  calls  free  during  its  execution,  we  use 
a  different  register  ri  to  hold  the  return  location  for  routine  malloc,  due  to  the 
lack  of  certified  activation  records.  The  well-formedness  of  all  the  other  code 
blocks  implementing  routine  malloc  are  modeled  similarly. 

Proving  these  theorems  is  not  much  different  than  proving  those  of  free.  A 
tricky  part  is  on  the  splitting  of  memory  blocks.  Similar  to  coalescing,  splitting 
temporarily  breaks  certain  invariants;  thus  it  is  hard  to  handle  in  conventional 
type  systems.  The  annotated  malloc  routine  in  CAP  is  shown  in  Figure  10  of 
Appendix  A  as  an  outline  of  the  proof. 


5  Example:  copy  program 

With  the  certified  implementation  (i.e.,  code  and  proof)  of  free  and  malloc, 
we  now  implement  a  certified  program  copy.  As  shown  in  Figure  7,  this  copy 
program  takes  a  pointer  to  a  list  as  the  argument,  makes  a  copy  of  the  list,  and 
disposes  the  original  one. 

To  make  use  of  the  certified  routines  free  and  malloc,  we  define  assertions 
for  the  list  data  structure  in  Figure  8.  (Pair  p  x  q)  defines  a  pair  at  location  p 
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list*  copy  (list*  src)  { 
target  =  prev  =  nil; 
while  (srcOnil)  { 

p  =  malloc(2);  \\  allocate  for  a  new  element 

p->data  =  src->data,  p->link  =  src->link;  \\  copy  an  element 

old  =  src,  src  =  src->link,  free(old);  \\  dispose  old  one 

if  (prev  ==  nil)  {target  =  p,  prev  =  p> 

else  {prev->link  =  p,  prev=p>  \\  link  in  new  element 


return  target; 

> 


Fig.  7.  Pseudo  code  of  copy 


which  stores  values  x  and  q;  it  carries  the  fact  that  it  resides  inside  a  “malloced” 
memory  block.  (Slist  a  p  q)  defines  a  list  with  the  help  of  Pair;  it  represents  a 
list  segment  from  p  to  q  representing  the  sequence  a.  The  structure  of  the  Slist 
definition  is  close  to  that  of  MBIkLst  and  Reynolds’  singly-linked,  list  [19, 18]. 

The  MBIk  assertion  carried  inside  Pair  is  crucial  for  the  memory  block  to  be 
“freed”  when  required.  It  has  to  be  preserved  throughout  the  copy  program. 
Typically  when  operating  on  a  pair  at  location  p,  only  locations  p  and  p  +  1 
are  referred  to.  Thus  as  long  as  the  header  of  the  memory  block  is  untouched, 
preserving  MBIk  is  straightforward. 

Certifying  the  copy  program  involves  the  following  steps:  (1)  write  the  plain 
code;  (2)  write  the  code  heap  spec;  (3)  prove  the  well-formedness  of  the  code  with 
respect  to  the  spec,  with  the  help  of  the  library  proofs.  Figure  11  of  Appendix  A 
shows  the  copy  program  with  annotations  at  various  program  points. 

The  spec  for  the  code  blocks  that  implement  the  copy  program  depends 
on  what  property  one  wants  to  achieve.  In  our  example,  we  specify  the  partial 
correctness  that  if  copy  ever  completes  its  task  (by  jumping  to  halt),  the  result 
list  contains  the  same  sequence  as  the  original  one. 

We  get  the  specs  of  the  library  blocks  by  instantiating  the  spec  templates 
of  the  previous  section  with  appropriate  assertion  Pred.  The  only  place  where 
malloc  is  called  is  in  block  nxtO  of  copy.  Inspecting  the  assertion  at  that  place 
and  the  spec  template,  we  instantiate  Pred  appropriately  to  get  the  actual  spec. 
Although  free  is  called  only  once  in  program  copy  (in  block  nxtl),  it  has  another 
call-site  in  block  more  of  malloc.  Thus  for  any  block  of  free,  there  are  two 
instantiated  specs,  one  customized  for  copy  (Ai)  and  the  other  for  malloc  (A2). 
The  actual  spec  that  we  use  is  the  disjunction  of  these  two  {A\  V  A2). 

The  well-formedness  of  the  program  can  be  derived  from  the  well-formedness 
of  all  the  code  blocks.  We  follow  the  proof  outline  in  Figure  11  to  handle  the 
blocks  of  copy.  For  the  blocks  of  routine  malloc,  we  directly  import  their  well- 
formedness  theorems  described  in  the  previous  section.  Proving  the  premises  of 
these  theorems  {e.g.,  Ainit  =>!?( init))  is  trivial  {e.g.,  Ainit  is  exactly  S'(init)). 
For  routine  free  whose  spec  has  a  disjunction  form,  we  apply  Rule  12  to  break 
up  the  disjunction  and  apply  the  theorems  twice.  Proving  the  premises  of  these 
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Pair  p  x  q  =  V(H,  R).  3lnk.  3 siz.  (H(p)  =  x)  A  (H(p  +  1)  =  q) 

A(MBIk  p  Ink  siz)  A  ( siz  —  2  >  2) 

Slist  e  p  q  =  empA(p  =  q) 

Slist  (x-a)  p  q  =  3p'.(Pair  p  x  p')*(Slist  a  p  q) 

Fig.  8.  Pair  and  Slist. 


theorems  involves  or- elimination  of  the  form  A\  ==>A\  V  A2,  which  is  also  triv¬ 
ial.  We  refer  interested  readers  to  our  implementation  [21]  for  the  exact  details. 

6  Related  Work  and  Future  Work 

Dynamic  storage  allocation  Wilson  et  al.  [22]  categorized  allocators  based  on 
strategies  (which  attempt  to  exploit  regularities  in  program  behavior),  place¬ 
ment  policies  (which  decide  where  to  allocate  and  return  blocks  in  memory), 
and  mechanisms  (which  involve  the  algorithms  and  data  structures  that  im¬ 
plement  the  policy).  We  believe  that  the  most  tricky  part  in  certifying  various 
allocators  is  on  the  low-level  mechanisms,  rather  than  the  high-level  strategies 
and  policies.  Most  allocators  share  some  subsidiary  techniques,  such  as  splitting 
and  coalescing.  Although  we  only  provided  a  single  allocation  library  implement¬ 
ing  a  particular  policy,  the  general  idea  used  to  certify  the  techniques  of  splitting 
and  coalescing  can  be  applied  to  implement  other  policies. 

Hoare  logic  Our  logic  reasonings  about  memory  properties  directly  follow  Reynolds’ 
separation  logic  [19,18].  However,  being  at  an  assembly  level,  CAP  has  some 
advantages  in  the  context  of  mechanical  proof-checking.  CAP  provides  a  fixed 
number  of  registers.  So  the  dynamic  state  is  easier  to  model  than  using  infi¬ 
nite  number  of  variables,  and  programs  are  free  of  variable  shadowing.  Being 
at  a  lower-level  implies  that  the  compiler  is  easier  to  build,  hence  it  engages  a 
smaller  Trusted  Computing  Base  (TCB).  Defining  assertions  as  CiC  terms  of 
type  State— > Prop,  as  opposed  to  defining  assertions  syntactically,  is  also  crucial 
for  mechanical  proof-checking  and  thus  for  PCC.  Another  difference  is  that  we 
establish  the  soundness  property  using  a  syntactic  approach. 

Filliatre  [5,6]  developed  a  software  certification  tool  Why  which  takes  an¬ 
notated  programs  as  input  and  outputs  proof  obligations  based  on  Hoare  logic 
for  proof  assistants  Coq  and  PVS.  It  is  possible  to  apply  Why  in  the  PCC 
framework,  because  the  proof  obligation  generator  is  closely  related  to  the  veri¬ 
fication  condition  generator  of  PCC.  However,  it  is  less  clear  how  to  apply  Why 
to  Foundational  PCC  because  the  proof  obligation  generator  would  have  to  be 
trusted.  On  the  other  hand,  if  Why  is  applied  to  certify  memory  management,  it 
is  very  likely  to  hit  problems  such  as  expressing  inductively  defined  assertions. 
Our  treatment  of  assertions  in  mechanical  proof-checking  can  be  used  to  help. 

Certifying  compilation  This  paper  is  largely  complementary  to  existing  work 
on  certifying  compilation  [16, 12,3, 1].  Existing  work  have  only  focused  on  pro- 
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grams  whose  safety  proofs  can  be  automatically  generated.  On  contrast,  we 
support  general  properties  and  partial  program  correctness,  but  we  rely  on  the 
programmer  to  construct  the  proof.  Nevertheless,  we  believe  this  is  necessary  for 
reasoning  about  program  correctness.  Automatic  proof  construction  is  infeasible 
because  the  problem  in  general  is  undecidable.  Our  language  can  be  used  to  for¬ 
mally  present  the  reasonings  of  a  programmer.  With  the  help  of  proof-assistants, 
proof  construction  is  not  difficult,  and  the  result  can  be  mechanically  checked. 

Future  work  Exploring  the  similarity  appeared  between  Hoare-logic  systems  and 
type  systems,  we  intend  to  model  types  as  assertion  macros  in  CAP  to  ease  the 
certifying  task.  For  instance,  a  useful  macro  is  the  type  of  a  memory  block 
(MBIk).  With  lemmas  ( c.f .,  typing  rules)  on  how  this  macro  interacts  with  com¬ 
mands,  users  can  propagate  it  conveniently.  If  one  is  only  interested  in  common 
properties,  ( e.g .,  operations  are  performed  only  on  allocated  blocks),  it  is  promis¬ 
ing  to  achieve  proof  construction  with  little  user  directions,  or  automatically. 

In  the  future,  it  would  be  interesting  to  develop  high-level  (e.g.,  C-like  or 
Java-like)  surface  languages  with  similar  explicit  specifications  so  that  programs 
are  written  at  a  higher-level.  “Proof-preserving”  compilation  from  those  lan¬ 
guages  to  CAL  may  help  retain  a  small  trusted  computing  base. 

7  Conclusion 

Existing  certifying  compilers  have  only  focused  on  programs  whose  safety  proofs 
can  be  automatically  generated.  In  complementary  to  these  work,  we  explored  in 
this  paper  how  to  certify  general  properties  and  program  correctness  in  the  PCC 
framework,  letting  programmers  provide  proofs  with  help  of  proof  assistants.  In 
particular,  we  presented  a  certified  library  for  dynamic  storage  allocation  —  a 
topic  hard  to  handle  using  conventional  type  systems.  The  logic  reasonings  on 
memory  management  largely  follow  separation  logic.  In  general,  applying  Hoare- 
logic  reasonings  in  the  PCC  framework  yields  interesting  possibilities. 
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free  :  {(MBIk  fptr  _  _)  *  (Good  (list) 

*Pred  AR(ro)  =  f} 
subi  hp,fptr,  2; 
movi  prev,  nil; 
mov  p,  flist; 

{(MBIk  ( hp  +  2)  _  _)  *  (MidL  flist  prev  p) 

*Pred  A  R(ro)  =  f  A  ( prev  =  nil)} 
jd  iter; 

next  :  {(MBIk  (hp  +  2)  _  _)  *  (MidL  flist  prev  p) 

*Pred  A  R(ro)  =  f  A  (p  ^  nil) 

A( prev  <  hpV prev  —  nil)} 
bgt  p,  hp,  tryh; 

{(MBIk  (hp  +  2)  _  _)  *  (MidL  flist  prev  p) 

*Pred  A  R(ro)  =  f  A  (p  <  hp)  A  (p  ^  nil)} 
mov  prev,p-, 

Id  p,p(link); 

{(MBIk  (hp  +  2)  _  -)  *  (MidL  flist  prev  p) 

*Pred  A  R(ro)  =  f  A  (prev  <  hp)} 

jd  iter; 

njhi  :  {(MBIk  (hp  +  2)  _  s)  *  (MidL  flist  prev  p) 

*Pred  A  R(ro)  =  f  A  (p  >  hp  +  s) 

A(prev  <  hpV  prev  =  nil)} 
st  hp(link),p; 

{(MBIk  (hp  +  2)  p  s)  *  (EndL  flist  prev  p) 

*(MBIkLst  n  p  nil)  *  Pred 
AR(ro)  =  f  A  (hp  <  p) 

A(prev  <  hpW  prev  =  nil)} 
jd  tryl; 

tryl  :  {(EndL  flist  prev  _)  *  Pred 
*(MBIkLst  (n  +  X)  hp  nil) 

AR(ro)  =  f  A  (prev  <  ftp  V  prev  =  nil)} 
bgti  prev, nil,  lnkl; 

{(EndL  flist  prev  -)  *  Pred 
*(MBIkLst  (n  +  1)  hp  nil) 

AR(ro)  =  f  A  (prev  =  nil)} 
mov  flist,  hp\ 

{(Good  flist)  *  Pred  A  R(ro)  =  f } 
jmp  r0; 

njlo  :  {(MBIkLst  m  flist  prev) 

*(MBIk  (prev  +  2)  _  prevsize) 

*(MBIkLst  (n  +  1)  hp  nil)  *  Pred 
AR(ro)  =  f  A  (prev  <  hp) 

A  (prev  +  prevsize  <  hp)} 
st  pret)(link),/ip; 

{(Good  flist)  *  Pred  A  R(ro)  =  f } 
jmp  r0; 

where  link  =  0,  size  =  1  and  nil  =  0;  variables  are  shorthands  for  registers. 


iter  :  {(MBIk  (hp  +  2)  _  _)  *  Pred 

*(MidL  flist  prev  p)  A  R(ro)  =  f 
A  (prev  <  hpV  prev  =  nil)} 
bgti  p, nil, next; 
st  /ip(link),p; 
jd  tryl; 

tryh  :  {(MBIk  (hp  +  2)  _  _)  *  Pred 

*(MidL  flist  prev  p)  A  R(ro)  =  f 
A (p  yt  nil)  A  (hp  <  p) 

A  (prev  <  hp  V  prev  =  nil)} 

Id  cur  size,  /ip(size); 
add  curend,  hp,  cur  size-, 
bgt  p,  citrend,njhi; 

{(MBIk  (hp  +  2)  _  cursize)  *  Pred 
*(MidL  flist  prev  p)  A  R(ro)  =  f 
A  (prev  <  hpV  prev  =  nil) 

A  (p  =  hp  +  cursize  ±  nil)} 

Id  psize,p( size); 

add  new  size,  cur  size, psize-, 

st  hp(size),newsize-, 

Id  plink,p( link); 
st  hp(liiik),plink-, 

{(MBIk  (hp  4-  2)  q  _)  *  Pred 
*(EndL  flist  prev  p) 

*(MBIkLst  n  q  nil)  A  R(ro)  =  f 
A  (prev  <  hpV  prev  =  nil) 

A  (hp  <  g  V  q  —  nil)} 
jd  tryl; 

lnkl  :  {(MBIkLst  m  flist  prev) 

*(MBIk  (prev  +  2)  .  s)  A  R(ro)  =  f 
*(MBIkLst  (n  +  1)  hp  nil)  *  Pred 
A  (prev  <  hp)  A  (prev  nil)} 

Id  prevsize,  prev  (size); 
add  prevend, prev, prevsize-, 
bgt  hp,  prevend,  njlo; 

{(MBIkLst  m  flist  prev) 

*(MB!k  (prev  +  2)  _  prevsize ) 
*(MBIkLst  (n  +  1)  hp  nil)  *  Pred 
AR(ro)  =  f  A  (prev  <  hp) 

A  (prev  +  prevsize  =  hp)} 

Id  cursize, hp( size); 

add  newsize,  prevsize,  cursize; 

Id  curlink,hp(liiik.)-, 
st  prev(size),newsize-, 
st  preti(link),  curlink ; 

{(Good  flist)  *  Pred  A  R(ro)  =  f } 
jmp  r0; 


Fig.  9.  Annotated  program  of  free. 
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malloc  :  { Pred  *  (Good  flist) 

A (nsize  =  so  >  0)  A  R(ri)  =  f} 
addi  bsize,nsize,  2; 
jd  init; 


mod  :  {Pred  *  (Good  flist)  A  R(ri)  =  f  A 
(0  <  so  +  2  <  bsize  <  N ALLOC)} 
mov  bbsize,  N ALLOC; 
jd  more; 


init  :  {Pred  *  (Good  flist) 

A(0  <  so  +  2  <  bsize)  A  R(ri)  =  f} 
movi  prev, nil; 
mov  p,  flist-, 

{Pred  *  (MidL  flist  prev  p) 

A(0  <  so  +  2  <  bsize)  A  R(ri)  =  f} 
jd  miter; 

miter  :  {Pred  *  (MidL  flist  prev  p) 

A(0  <  so  +  2  <  bsize)  A  R(ri )  =  f } 
bgti  p,nil,  comp; 
bgt  N ALLOC,  bsize, mod; 

{Pred  *  (Good  flist) 

A(0  <  so  +  2  <  bsize)  A  R(ri )  =  f } 
mov  bbsize,  bsize-, 
jd  more; 


split  :  {Pred  *  (EndL  flist  prev  p) 

*(MBIk  {p  +  2)  q  psize) 

*(MBIkLst  n  q  nil)  A  R(n)  =  f 
A(0  <  so  +  2  <  bsize  <  psize  —  2) 
A {p  <  qV  q  —  nil)} 
sub  psize, psize,  bsize-, 
st  p(size), psize-, 
add  p,p,  psize-, 
st  p(size),  bsize-, 

{Pred  *  (EndL  flist  prev  p') 
*(MBIk  (p'  +  2)  q  ( psize  —  bsize)) 
*(MBIk  (p  +  2)  _  bsize) 

*(MBIkLst  n  q  nil)  A  R(ri)  =  1 
A(0  <  so  +  2  <  bsize  <  psize  —  2) 
A(p'  <gVg  =  nil)} 
jd  retptr; 


comp  :  {Pred  *  (MidL  flist  prev  p)  A  R(n)  =  t 
A(0  <  so  +  2  <  bsize)  A  (p  ji  nil)} 

Id  psize, p{ size); 
addi  ebsize,bsize,2 ; 
bgt  psize,  ebsize,  split; 

{Pred  *  (EndL  flist  prev  p) 

■  *(MBIk  (p  +  2)  q  psize)  *  (MBIkLst  n  q  nil) 
A(0  <  so  4-  2  <  bsize)  A  R(ri)  =  f 
A (p  <  q  V  q  —  nil)} 
bgt  bsize, psize, mnext; 

{Pred  *  (EndL  flist  prev  p) 

*(MBIk  (p  +  2)  q  psize) 

*(MBIkLst  n  q  nil) 

A(so  +  2  <  bsize  <  psize)  A  R(ri)  =  f 
A(p  <  9  V  q  —  nil)} 

Id  plink,p(link)-, 
bgti  preu, nil,  lprv; 

{Pred  *  (EndL  flist  nil  p) 

*(MBIk  (p  +  2)  plink  psize) 

*(MBIkLst  n  plink  nil) 

A(so  +  2  <  psize)  A  R(ri)  =  f} 
mov  flist,  plink; 

{Pred  *  (MBIk  (p  +  2)  plink  psize ) 
*(MBIkLst  n  flist  nil) 

A(so  +  2  <  psize)  A  R(ri)  =  f } 
jd  retptr; 


mnext  :  {Pred  *  (EndL  flist  prev  p) 
*(MBIk  (p  +  2)  q  s) 

*(MBIkLst  n  q  nil)  A  R(ri)  =  f 
A(0  <  so  +  2  <  bsize) 

A(p  <  q  V  q  =  nil)} 
mov  prev,p; 

Id  p,p(link); 

{Pred  *  (EndL  flist  prev  p) 
*(MBIkLst  n  p  nil)  A  R(ri)  =  f 
A(0  <  so  +  2  <  bsize)} 
jd  miter; 

lprv  :  {Pred  *  (EndL  flist  prev  p) 

*(MBIk  (p  +  2)  plink  s)* 

(MBIkLst  n  plink  nil)  AR(rj)  =  f 
A(so  +  2  <  s)  A  ( prev  ^  nil) 

A (p  <  plink  V  plink  =  nil)} 
st  prev  (link),  plink; 

{Pred  *  (EndL  flist  prev  plink) 
*(MBIk  (p  +  2)  plink  s) 

*(MBIkLst  n  plink  nil) 

A(so  +  2  <  s)  A  R(ri)  =  f} 
jd  retptr; 


retptr  :  {Pred  *  (Good  flist)  *  (MBIk  (p  +  2)  _  s) 
A(so  +  2  <  s)  A  R(rj)  =  f } 
addi  mptr,p,  2; 

{Pred'  *  (Good  flist)  *  (MBIk  mptr 
A(so  +  2  <  s)  A  R(ri)  —  i} 
jmp  ft; 


where  link  =  0,  size  =  1  and  nil  =  0; 


e  :  {Pred*  (Good  flist)  AR(ri)  =  f 
A(0  <  so  +  2  <  bsize  <  bbsize)} 
alloc  newp[bbsize]; 
st  netup(size),  bbsize; 
addi  fptr,newp,  2; 
movi  ro,  init; 

{(Good  flist)  *  (MBIk  fptr  _  bbsize) 
*Pred  A  (0  <  so  +  2  <  bsize) 
AR(ri)  —  f  A  R(ro)  =  init} 
jd  free; 

variables  are  shorthands  for  registers. 


■s) 


Fig.  10.  Annotated  program  of  malloc. 
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copy  :  {3a.  (Slist  a  src  nil)  *  (Good  fhst)  nxtl  : 

A  (a  =  ao)} 
movi  tgt,  nil; 
movi  cprev, nil; 
jd  test; 

test  :  {{{{cprev  =  nil) 

3  3a.  (Slist  a  src  nil)  A  (a  =  ao) 

A  (tgt  =  nil)) 

A  ((cprev  yt  nil) 

33a.  30. 3b.  {0-b-a  =  ao) 

A(Slist  a  src  nil)  *  (Slist  (3  tgt  cprev) 

*(Pair  cprev  b  src))) 

*(Good  flist)} 
bgti  src,  nil,  nxtO; 
jd  halt; 

nxtO  :  {{{{cprev  =  nil) 

3  3a.  3a.  3 i.  (Pair  src  a  i)  *  (Slist  a  i  nil) 

A(a-a  =  ao)  A  ( tgt  =  nil)) 

A{{cprev  yi  nil) 

33a.  3a.  30.  3b.  3 i.  ( 0-b-a-a  =  ao) 

A(Pair  src  a  i)  *  (Slist  a  i  nil) 

*(Slist  0  tgt  cprev) 

*(Pair  cprev  b  src))) 

*(Good  flist)} 
movi  nsize,  2; 
movi  ri,nxtl; 

{{{{cprev  =  nil) 

33a.  3a.  3i.  (Pair  src  a  i)  *  (Slist  a  i  nil) 

A(a-a  =  ao)  A  {tgt  =  nil)) 

A{{cprev  yi  nil)  nxt;2  . 

33a.  3a.  30.  36.  3 i.  {0-b-a-a  =  ao) 

A(Pair  src  a  i)  *  (Slist  a  i  nil) 

*(Slist  0  tgt  cprev) 

*(Pair  cprev  b  src))) 

*(Good  flist)  A  {nsize  =  2)  A  (rj  =  nxtl)} 
jd  malloc; 

lnkp  :  {{{{cprev  nil) 

A  3a.  3a.  30. 3b.  (Pair  mptr  a  src) 

*(Slist  a  src  nil)  *  (Slist  0  tgt  cprev) 

*(Pair  cprev  b  fptr)  A  {0-b-a-a  =  ao))) 
*(Good  flist)} 
st  cprev{l),mptr; 
mov  cprev,  mptr-, 

{{{{cprev  yi  nil) 

A  3a.  3a.  30.  (Pair  cprev  a  src) 

*(Slist  a  src  nil) 

*(Slist  0  tgt  cprev)  A  {0-a-a  =  ao))) 

*(Good  flist)} 
jd  test; 

halt  :  {3/3.  (Slist  0  tgt  nil)  *  (Good  flist) 

A(/3  =  a0)} 

jd  halt; 

where  nil  =  0;  variables  are  shorthands  for  registers. 


{{{{cprev  =  nil) 

3  3a.  3a.  3i.  (Pair  src  a  i) 

*(Slist  a  i  nil)  A  (a  a  =  ao) 

A  {tgt  =  nil)) 
f\{{cprev  y£  nil) 

3  3(a,  a, 0,b,i).  {0-b-a-a  =  ao) 
A(Pair  src  a  i)  *  (Slist  a  i  nil) 
*(Slist  0  tgt  cprev) 

*(Pair  cprev  b  src))) 

*(Good  flist)  *  (MBIk  mptr  _  siz) 
A{siz  >  4)} 

Id  temp,  src(O); 
st  mptr (0),  temp-, 
mov  fptr,  src, 

Id  src,src(l); 
st  mptr{  1),  src; 
movi  ro,nxt2 
{(((cpreti  =  nil) 

3  3a.  3a.  (Pair  mptr  a  src) 

♦(Slist  a  src  nil)  A  (a -a  =  ao) 
A  {tgt  —  nil)) 

A  {{cprev  nil) 

3  3a.  3a.  30.  3b.  {0-b-a-a  —  ao) 
A(Pair  mptr  a  src) 

♦  (Slist  a  src  nil) 

♦(Slist  0  tgt  cprev) 

*(Pair  cprev  b  fptr))) 

*(MB!k  fptr  -  -)  *  (Good  flist) 
A(ro  —■  nxt2)} 
jd  free; 

{{{{cprev  =  nil) 

3  3 a.  3a.  (Pair  mptr  a  src ) 

♦  (Slist  a  src  nil)  A  (a-a  =  ao) 
A  {tgt  =  nil)) 

A{{cprev  nil) 

3  3a.  3a.  30. 36.  {0-b-a-a  =  ao) 
A(Pair  mptr  a  src) 

♦(Slist  a  src  nil) 

♦  (Slist  0  tgt  cprev) 

*(Pair  cprev  b  fptr))) 

*(Good  flist)} 
bgti  cprev,  nil,  lnkp; 

{3a.  3a.  (Pair  mptr  a  src) 

♦  (Slist  a  src  nil)  A  (a-a  =  ao) 
A{tgt  =  nil) 

*(Good  flist)  A  {cprev  =  nil)} 
mov  tgt,  mptr; 
mov  cprev,  tgt; 

{3a.  3a.  (Pair  cprev  a  src) 

♦  (Slist  a  src  nil)  A  (a-a  =  ao) 

A  {cprev  =  tgt) 

*(Good  flist)  A  {cprev  yi  nil)} 
jd  test; 


Fig.  11.  Annotated  program  of  copy:  copies  a  null-terminated  list  from  src  to  tgt. 
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